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PATENT 
Docket No. LS/0026.00 

ORDER SCHEDULING SYSTEM AND METHODOLOGY 
COPYRIGHT NOTICE 

5 A portion of the disclosure of this patent document contains material which is subject 

to copyright protection. The copyright owner has no objection to the facsimile reproduction 
by anyone of the patent document or the patent disclosure as it appears in the Patent and 
Trademark Office patent file or records, but otherwise reserves all copyright rights 
whatsoever. 

10 BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to the field of order fulfillment and, more particularly, 
to system and methodology for efficiently managing order fulfillment. 



15 2. Description of the Background Art 

Despite advances afforded by e-commerce, a fundamental problem still exists today 
in terms of how to efficiently fulfill an order that has been placed by a customer. This 
problem typically faces those who take customer orders, that is, the "middlemen" (which is 
used herein to broadly refer to retailers, distributors, or the like). Often, a middleman will 

20 have to send a customer order to a "fulfiller," that is, an organization that will fulfill the order 
by actually shipping ordered goods back to the customer. The considerations involved in 
choosing a particular fulfiller are numerous, but typically a middleman chooses a fulfiller 
with the primary goal of minimizing costs, thus maximizing profits. Different cost-related 
constraints may come into play, when striving to maximize profit. For example, in addition 

25 to the cost incurred as a result of the price charged by a given fulfiller, other cost 

considerations include what shipping charges are incurred when shipping from a given 
fulfiller. One fulfiller may have a better price, but that price advantage may be negated by 
unfavorable shipping charges. Further, cost is not the only factor to consider. Instead, at 
least some consideration must be given to the ability of a particular fulfiller to timely fulfill 
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an order. There is no point in choosing a fulfiller who offers the best price, if that fulfiller 
lacks sufficient inventory to successfully fulfill the order in a reasonable period of time. 

Often an order cannot be completely fulfilled, or supplied, by a single fulfiller; 
therefore, the fulfillment of such an order is spread across multiple fulfillers. The 
5 determination of the distribution of sub-orders, or product orders within an order, to multiple 
fulfillers is the scheduling of order shipments for that order. Order shipment scheduling 
attempts to optimize the fulfiller distribution to minimize the shipping costs to either the 
customer or to the middleman processing the order. Minimizing the shipping costs almost 
invariably indicates minimizing the number of fulfillers satisfying an order. Optimized 
10 scheduling also minimizes delivery time, and satisfies any arbitrary business logic, such as 
favoring specified fulfillers (when more than one fulfiller can deliver the same order item in 
an order). The middleman needs to efficiently optimize the order shipment(s) scheduling 
according to whatever constraints he or she uses as criteria for assigning order items to 
fulfillers. 

15 Previous attempts to automate (by computer programming) the optimization of order 

shipment scheduling have not been satisfactory. Current methods involve considerable time 
for programming development/updating, and require costly compute time. The prevailing 
approach uses the simplex method for solving the linear programs comprising multiple 
simultaneous linear equations; see, e.g., Anderson, David Ray, An Introduction to 

20 Management Science: Quantitative Approaches to Decision Making, Seventh Edition, 

Chapter 5 (particularly at pp. 190-192), West Publishing Company, 1994, the disclosure of 
which is hereby incorporated by reference. This approach develops a linear programming 
model comprising a set of linear equations: each linear equation describes a constraint (e.g., 
proximity of shipper-to-shipping recipient) to be applied to all potential fulfillers. 

25 A linear equation solves for a single variable, and takes the form: ax + b = 0, where x 

is the unknown variable, and both a and t> are constant numerical values. In linear equations, 
the variable, x, always has its exponential value set to 1; exponential or logarithmic variable 
types are not employed as operands in linear equations. Each linear equation can be graphed 
as a straight line in a two-dimensional XY-coordinate plane. The coefficient for the variable 

30 (the constant numerical value of a, in the generic form) determines the slope of the straight 
line for that equation. This equation is processed for every fulfiller considered. If the 
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scheduling method implements multiple constraints, then a separate linear equation is 
processed against each constraint simultaneously. Multiple linear equations can be mapped 
onto a two-dimensional graph. The set of possible solutions (that minimizes for these 
constraints) is bound by the area beneath the intersections of the straight line on the graph. 

5 Fig. 1 is an XY two-dimensional coordinate graph showing the slopes for three 

separate linear equations representing three constraints in a problem for scheduling types of 
personal computers (e.g., DeskPro™): warehouse capacity, display units, and assembly time. 
Fig. 1 includes the slope 100 for the equation constraining warehouse capacity, the slope 110 
for the equation constraining display units, the slope 120 for the equation constraining 

10 assembly time, the area-bounding intersection 130 of the X and Y axes at value (0,0), the 
area-bounding intersection 140 of the warehouse capacity slope 100 and the X-axis, the area- 
bounding intersection 150 of the assembly time slope 120 and the warehouse capacity slope 
100, the area-bounding intersection 160 of the display units slope 1 10 and the assembly time 
slope 120, and the area-bounding intersection 170 of the Y-axis and the display units slope 

15 1 10. The area bound by the intersections in Fig. 1, 130, 140, 150, 160, and 170, contains the 
set of feasible solutions for this problem. A discrete solution for any variable (constraint) can 
be determined by holding all the other variables' values at a constant (within the feasible set). 

Current systems using linear programming with multiple simultaneous equations 
leave much to be desired. A well-known problem with linear solutions is that the simplex 

20 method requires intensive iteration. Computerized solutions for multiple simultaneous 

equations are therefore time-consuming. Another deficiency with linear programming is the 
programmatic difficulty in setting-up the equations. Because the constraints can be described 
in linear equations with inequalities, it is challenging to program a general solution that 
applies to every scenario. Full appreciation of all the factors defining the constraints cannot 

25 be completely known a priori. For example, if the program implements a policy towards 

minimizing shipping costs, the program would need to know all of the distances between the 
location of the middleman or the customer and the location of every fulfiller: that information 
would have to be put into a database, and extracted-out and placed into a coefficient for each 
iteration of each equation. The approach has a degree of fuzziness that stems from the 

30 implicit effects of other incidental variables, such as slack time (which is the consequence of 
having determined the best solution, there is always a remainder left over). 
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The simplex method of solving linear equations is not the only method; however, the 
other methods are even more difficult to implement. Because of the ever-increasing demands 
of the marketplace (and e-commerce marketplace) for timely, cost-effective fulfillment of 
customer orders, much interest exists in finding a solution to these problems. 
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GLOSSARY 



bit vector: A one-dimensional array of bit (e.g., 1 and 0) values, which is useful for 
specifying a sequence of Boolean (true/false) values. 

fulfiller: Fulfiller, as used herein, broadly refers to any entity capable of fulfilling an order or 
5 portions (i.e., order items) thereof, which may include a distributor, supplier, vendor, 
manufacturer, service bureau, or the like. Typically, the fulfiller receives orders from a 
middleman (e.g., retailer, or the like). The fulfiller may fulfill an order by shipping directly 
to the end customer, or by shipping to the middleman (who in turn ships to the end 
customer). 

10 HTTP: Short for HyperText Transfer Protocol, the underlying protocol used by the World 
Wide Web. HTTP defines how messages are formatted and transmitted, and what actions 
Web servers and browsers should take in response to various commands. For example, when 
a user enters a URL in his or her browser, this actually sends an HTTP command to the Web 
server directing it to fetch and transmit the requested Web page. Further description of 

15 HTTP is available in RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, the disclosure of 
which is hereby incorporated by reference. RFC 2616 is available from the World Wide 
Web Consortium (W3), and is currently available via the Internet at 
http://www. w3. org/ProtocolsA 

Java: A general purpose programming language developed by Sun Microsystems. Java is an 
20 object-oriented language similar to C++, but simplified to eliminate language features that 
cause common programming errors. Java source code files (files with a .Java extension) are 
compiled into a format called bytecode (files with a .class extension), which can then be 
executed by a Java interpreter. Compiled Java code can run on most computers because Java 
interpreters and runtime environments, known as Java Virtual Machines (JVMs), exist for 
25 most operating systems, including UNIX, the Macintosh OS, and Windows. Bytecode can 
also be converted directly into machine language instructions by a just-in-time compiler 
(JIT). 

Servlet: An applet that runs on a server. The term usually refers to a Java applet that runs 
within a Web server environment. This is analogous to a Java applet that runs within a Web 
30 browser environment. Java servlets are becoming increasingly popular as an alternative to 
CGI programs. The biggest difference between the two is that a Java applet is persistent. 
Once it is started, a servlet stays in memory and can fulfill multiple requests. In contrast, a 
CGI program disappears once it has fulfilled a request. The persistence of Java applets tends 
to make them faster. 

35 XML: Short for Extensible Markup Language, sl specification developed by the W3C. XML 
is a pared-down version of SGML, designed especially for Web documents. It allows 
designers to create their own customized tags, enabling the definition, transmission, 
validation, and interpretation of data between applications and between organizations. For 
further description of XML, see, e.g., Extensible Markup Language (XML) 1.0 specification 

40 which is available from the World Wide Web Consortium (www.w3.org), the disclosure of 
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which is hereby incorporated by reference. The specification is also currently available on 
the Internet at http://www.w3.org/TR/REC-xml 
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SUMMARY OF THE INVENTION 

An order scheduling system providing a method for distributing product orders to 
multiple fulfillers is described. This method solves the common business problem of 
scheduling order shipments. The method is both optimal and fair (among multiple otherwise- 
5 equal fulfillers). It is optimal because it minimizes the number of orders across fulfillers, 
thus minimizing shipping costs. It is fair because orders are distributed equally across 
fulfillers if that fulfiller has the product available. 

To schedule orders, a data structure is defined whose rows are represented by a hash 
table of Fulfillers (HF), where each column is a hash table of Products (HP) and where each 
10 index of HP is itself a bit vector (VPi). This gives a three-dimensional data structure. Here, 
the term "hash" is used to indicate that for a given fulfiller/product pair, the approach may 
"hash" (i.e., index on) that pair for indexing into a particular cell in the table. This 
fulfiller/product correspondence may also be represented by a two-dimensional array (e.g., 
accessible via numeric indexes). Although the information represented in the hash table may 
15 be derived from SQL queries submitted to a product/supplier database, it is more efficient to 
maintain this information in a relatively terse in-memory data structure, as the information 
will be repeatedly accessed. 

In contrast to using linear equations for representing this information, the hash table 
itself is extensible. If additional fulfillers or suppliers become available, the number of rows 
20 in the hash table is simply increased (or simply decreased to represent less). In a 

corresponding manner, the number of rows in the hash table may be increased or decreased 
to accommodate changes in the current product offerings. Thus, when changes occur, as they 
invariably will, the hash table may readily accommodate those changes. There is no 
requirement that the underlying program code be modified. 
25 Whether a particular fulfiller has a product available does not necessarily depend on 

that fulfillers inventory. Certainly, limited inventory poses a problem to product availability 
by a fulfiller. However, some products have effectively unlimited inventory. For example, 
the ability of a photofinisher to provide an almost unlimited number of reprints for a 
customer photograph is one such example. Here, the photofinisher (fulfiller) has effectively 
30 unlimited supply of photo-finishing paper available for completing the customer order (of 
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reprinting a photograph). Therefore, often the issue of whether a particular product is 
available from a given fulfiller depends on whether that fulfiller actually even offers that 
product to begin with. 

An order itself may be viewed as one or more order items (typically, corresponding to 
5 a particular product). In certain cases, it may be necessary to split a customer order among 
the multiple fulfillers, based on order items. For example, an order may be split into two 
order items, Oil and 012, in effect, two suborders. The order may be split by having one 
fulfiller, Fi, fulfill Oil, while a second fulfiller, F2, fulfills OI2. A VPi vector, which 
extends into the third dimension (z axis) of the above hash table, is potentially employed in 
10 such instances. The VPi vector allows tracking of what part of an order — specifically, what 
order item - was split and to which fulfiller. 

Using the above-described bit vectors, the method may perform bitwise ANDing (&) 
operations of the bit vectors. This generates an Order bit vector representing the optimized 
fulfillment (per system configuration/constraints) for a particular received order. 

15 
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BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a graph illustrating the simplex method for scheduling order fulfillment. 

Fig. 2 is a block diagram of a computer system in which software-implemented 
processes of the present invention may be embodied. 

Fig. 3 is a block diagram of a software system for controlling the operation of the 
computer system of Fig. 2. 

Fig. 4A is a diagram illustrating a hash table data structure employed in the system of 

the present invention. 

Fig. 4B is a diagram illustrating simple order splitting. 

Fig. 4C is a diagram illustrating more-complex order splitting. 

Fig. 5 A is a high-level block diagram illustrating a server-based order scheduling 
system of the present invention. 

Fig. 5B is a block diagram illustrating an order scheduler module of the order 

scheduling system. 

Fig. 5C is a block diagram illustrating a database schema employed by the order 
scheduling system. 

Fig. 6 is a flowchart illustrating overall operation of the order scheduling system of 
the present invention. 

Fig. 7 is a flowchart illustrating a coarse-grained optimization method for fulfilling an 
order with a relatively low number of fulfillers. 

Fig. 8 is a flowchart illustrating a method for minimizing shipping costs by placing 
order items with fulfillers geographically nearest to the delivery address. 
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DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT 

The following description will focus on the presently-preferred embodiment of the 
present invention, which is implemented in an Internet-connected server environment 
running under a server operating system, such as the Microsoft® Windows XP running on an 
5 IBM-compatible PC. The present invention, however, is not limited to any particular one 
application or any particular environment. Instead, those skilled in the art will find that the 
system and methods of the present invention may be advantageously embodied on a variety 
of different platforms, including Macintosh, Linux, BeOS, Solaris, UNIX, NextStep, 
FreeBSD, and the like. Therefore, the description of the exemplary embodiments that 
10 follows is for purposes of illustration and not limitation. 

I. Computer-based implementation 

A. Basic system hardware (e.g., for desktop and server computers) 

The present invention may be implemented on a conventional or general-purpose 
computer system, such as an IBM-compatible personal computer (PC) or server computer. 

15 Fig. 2 is a very general block diagram of an IBM-compatible system 200. As shown, system 
200 comprises a central processing unit(s) (CPU) or processor (s) 201 coupled to a random- 
access memory (RAM) 202, a read-only memory (ROM) 203, a keyboard 206, a pointing 
device 208, a display or video adapter 204 connected to a display device 205, a removable 
(mass) storage device 215 (e.g., floppy disk, CD-ROM, CD-R, CD-RW, or the like), a fixed 

20 (mass) storage device 216 (e.g., hard disk), a communication port(s) or interface(s) 210, a 
modem 212, and a network interface card (NIC) or controller 21 1 (e.g., Ethernet). Although 
not shown separately, a real-time system clock is included with the system 200, in a 
conventional manner. 

CPU 201 comprises a processor of the Intel Pentium® family of microprocessors. 

25 However, any other suitable microprocessor or microcomputer may be utilized for 

implementing the present invention. The CPU 201 communicates with other components of 
the system via a bi-directional system bus (including any necessary input/output (I/O) 
controller circuitry and other "glue" logic). The bus, which includes address lines for 
addressing system memory, provides data transfer between and among the various 
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components. Description of Pentium-class microprocessors and their instruction set, bus 
architecture, and control lines is available from Intel Corporation of Santa Clara, CA. 
Random-access memory 202 serves as the working memory for the CPU 201 . In a typical 
configuration, RAM of sixteen megabytes or more is employed. More or less memory may 
5 be used without departing from the scope of the present invention. The read-only memory 
(ROM) 203 contains the basic input output system code (BIOS) - a set of low-level routines 
in the ROM that application programs and the operating systems can use to interact with the 
hardware, including reading characters from the keyboard, outputting characters to printers, 
and so forth. 

10 Mass storage devices 215, 216 provide persistent storage on fixed and removable 

media, such as magnetic, optical or magnetic-optical storage systems, flash memory, or any 
other available mass storage technology. The mass storage may be shared on a network, or it 
may be a dedicated mass storage. As shown in Fig. 2, fixed storage 216 stores a body of 
program and data for directing operation of the computer system, including an operating 

15 system, user application programs, driver and other support files, as well as other data files of 
all sorts. Typically, the fixed storage 216 serves as the main hard disk for the system. 

In basic operation, program logic (including that which implements methodology of 
the present invention described below) is loaded from the storage device or mass storage 216 
into the main (RAM) memory 202, for execution by the CPU 201. During operation of the 

20 program logic, the system 200 accepts user input from a keyboard 206 and pointing device 
208, as well as speech-based input from a voice recognition system (not shown). The 
keyboard 206 permits selection of application programs, entry of keyboard-based input or 
data, and selection and manipulation of individual data objects displayed on the display 
screen 205. Likewise, the pointing device 208, such as a mouse, track ball, pen device, or the 

25 like, permits selection and manipulation of objects on the display screen. In this manner, 
these input devices support manual user input for any process running on the system. 

The computer system 200 displays text and/or graphic images and other data on the 
display device 205. The video adapter 204, which is interposed between the display 205 and 
the system, drives the display device 205. The video adapter 204, which includes video 

30 memory accessible to the CPU 201, provides circuitry that converts pixel data stored in the 
video memory to a raster signal suitable for use by a cathode ray tube (CRT) raster or liquid 
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crystal display (LCD) monitor. A hard copy of the displayed information, or other 
information within the system 200, may be obtained from the printer 207, or other output 
device. Printer 207 may include, for instance, an HP LaserJet® printer (available from 
Hewlett-Packard of Palo Alto, CA), for creating hard copy images of output of the system. 
5 The system itself communicates with other devices (e.g., other computers) via the 

network interface card (NIC) 211 connected to a network (e.g., Ethernet network), and/or 
modem 212 (e.g., 56K baud, ISDN, DSL, or cable modem), examples of which are available 
from 3Com of Santa Clara, CA. The system 200 may also communicate with local 
occasionally-connected devices (e.g., serial cable-linked devices) via the communication 

10 ("comm") interface 210, which may include a RS-232 serial port, a Universal Serial Bus 
(USB) interface, or the like. Devices that will be commonly connected locally to the 
interface 210 include laptop computers, handheld organizers, digital cameras, and the like. 

IBM-compatible personal computers and server computers are available from a 
variety of vendors. Representative vendors include Dell Computers of Round Rock, TX, 

15 Compaq Computers of Houston, TX, and IBM of Armonk, NY. Other suitable computers 
include Apple-compatible computers (e.g., Macintosh), which are available from Apple 
Computer of Cupertino, CA, and Sun Solaris workstations, which are available from Sun 
Microsystems of Mountain View, C A. 

B. Basic system software 

20 Illustrated in Fig. 3, a computer software system 300 is provided for directing the 

operation of the computer system 200. Software system 300, which is stored in system 
memory (RAM) 202 and on fixed storage (e.g., hard disk) 216, includes a kernel or operating 
system (OS) 310. The OS 310 manages low-level aspects of computer operation, including 
managing execution of processes, memory allocation, file input and output (I/O), and device 

25 I/O. One or more application programs, such as client application software or "programs" 
301 (e.g., 301a, 301b, 301c, 301d) may be "loaded" (i.e., transferred from fixed storage 116 
into memory 102) for execution by the system 100. 

System 300 includes a graphical user interface (GUI) 315, for receiving user 
commands and data in a graphical (e.g., "point-and-click") fashion. These inputs, in turn, 

30 may be acted upon by the system 100 in accordance with instructions from operating system 
310, and/or client application module(s) 301. The GUI 315 also serves to display the results 
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of operation from the OS 310 and application(s) 301, whereupon the user may supply 
additional inputs or terminate the session. Typically, the OS 310 operates in conjunction 
with device drivers 320 (e.g., "Winsock" driver — Windows' implementation of a TCP/IP 
stack) and the system BIOS microcode 330 (i.e., ROM-based microcode), particularly when 
5 interfacing with peripheral devices. OS 310 can be provided by a conventional operating 
system, such as Microsoft® Windows 9x, Microsoft® Windows NT, Microsoft® Windows 
3000, or Microsoft® Windows XP, all available from Microsoft Corporation of Redmond, 
WA. Alternatively, OS 310 can also be an alternative operating system, such as the 
previously- mentioned operating systems. 

10 The above-described computer hardware and software are presented for purposes of 

illustrating the basic underlying desktop and server computer components that may be 
employed for implementing the present invention. For purposes of discussion, the following 
description will present examples in which it will be assumed that there exists at least one 
host computer (e.g., "server") that may communicate with one or more other computers (e.g., 

15 "clients"). The present invention, however, is not limited to any particular environment or 
device configuration. Instead, the present invention may be implemented in any type of 
system architecture or processing environment capable of supporting the methodologies of 
the present invention presented in detail below. 

II. Order scheduler 

20 A. Introduction 

Existing order fulfillment systems typically include a database of products (that are 
being sold to customers), with the database tracking which product can be fulfilled or 
supplied by which fulfiller(s). Thus, an existing one-to-many relationship of product to 
fulfiller/supplier is often already tracked in conventional fulfillment systems. For a given 

25 row (record) of product represented in the database, a given supplier either has or does not 
have that product; this may be represented as a simple Boolean (true/false) value. In the 
aggregate (i.e., for multiple fulfillers), availability by fulfiller may be represented by a bit 
vector (i.e., a one-dimensional array of bit values), where a bit value of 1 represents true (i.e., 
the fulfiller has the product) and a bit value of 0 represents false (i.e., the fulfiller does not 

30 have the product). By using bit vectors to represent this information (which itself may be 
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extracted from a product/fulfiller database), the task of programming an appropriate solution 
is simplified. 

B, Overview 

The following description presents a method for distributing product orders to 
5 multiple fulfillers. This method solves the common business problem of scheduling order 
shipments. The method is both optimal and fair (among multiple otherwise-equal fulfillers). 
It is optimal because it minimizes the number of orders across fulfillers, thus minimizing 
shipping costs. It is fair because orders are distributed equally across fulfillers if that fulfiller 
has the product available. 

10 To schedule orders, a data structure is defined whose rows are represented by a hash 

table of Fulfillers (HF), where each column is a hash table of Products (HP) and where each 
index of HP is itself a vector (VPi). This gives the three-dimensional data structure shown in 
Fig. 4A. Here, the term "hash" is used to indicate that for a given fulfiller/product pair, the 
approach may "hash" (i.e., index on) that pair for indexing into a particular cell in the table. 

15 This fulfiller/product correspondence may also be represented by a two-dimensional array 
(e.g., accessible via numeric indexes). Although the information represented in the hash 
table may be derived from SQL queries submitted to a product/supplier database, it is more 
efficient to maintain this information in a relatively terse in-memory data structure, as the 
information will be repeatedly accessed. 

20 In contrast to using linear equations for representing this information, the hash table 

itself is extensible. If additional fulfillers or suppliers become available, the number of rows 
in the hash table is simply increased (or simply decreased to represent less). In a 
corresponding manner, the number of rows in the hash table may be increased or decreased 
to accommodate changes in the current product offerings. Thus, when changes occur, as they 

25 invariably will, the hash table may readily accommodate those changes. There is no 
requirement that the underlying program code be modified. 

Whether a particular fulfiller has a product available does not necessarily depend on 
that fulfiller's inventory. Certainly, limited inventory poses a problem to product availability 
by a fulfiller. However, some products have effectively unlimited inventory. For example, 

30 the ability of a photofinisher to provide an almost unlimited number of reprints for a 
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customer photograph is one such example. Here, the photofinisher (fulfiller) has effectively 
unlimited supply of photo-finishing paper available for completing the customer order (of 
reprinting a photograph). Therefore, often the issue of whether a particular product is 
available from a given fulfiller depends on whether that fulfiller actually even offers that 
5 product to begin with. 

An order itself may be viewed as one or more order items (typically, corresponding to 
a particular product). In certain cases, it may be necessary to split a customer order among 
the multiple fulfillers, based on order items. Fig. 4B illustrates this concept. There, the order 
has been split into two order items, Oil and 012, in effect, two suborders. As shown, the 

10 order has been split by having one fulfiller, Fi, fulfill Oil, while a second fulfiller, F2, 

fulfills OI2. The VPi vector, which extends into the third dimension (z axis), is potentially 
employed in such instances. The VP} vector allows tracking of what part of an order - 
specifically, what order item - was split and to which fulfiller it was split to. Fig. 4C 
illustrates this concept. Suppose an order consists of three order items: a 5x7 reprint of a dog 

15 photograph (product type of Pi), a 5x7 reprint of a cat photograph (also product type of Pi), 
and a coffee mug embossed with a bird photograph (product type of P2). To track that 
fulfiller Fi is to fulfill the order items of type Pi, Oil and OI2 are entered in the VPi vector 
that is indexed by Fi and Pi. 

C. Example: Setting up bit vectors 

20 To understand how the order scheduler methodology works, consider the following 

example, which illustrates use of bit vectors. An order may contain any or all of the 
following products. 

Pi 4x6 photographic print 
25 P 2 8x10 photographic print 

P 3 coffee mug embossed with photo 

The fulfillment system will have one or more fulfillers that can be chosen to fill the order. 
However, not every fulfiller may have all products. 

30 
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Fj 4X6 print, coffee mug (2 products) 

F 2 coffee mug (1 product) 

F 3 4x6 print, 8x10 print, coffee mug (3 products) 



5 The function F 1 . count ( ) returns 2. 

In order to represent the products a fulfiller can supply, a bit vector is used, as 
follows: 

Fi.bv[101] (which is PI and P3) 
10 F 2 .bv[001] (which is P3) 

F 3 .bv[lll] (which is PI, P2 andP3) 

An Order is a sequence of Orderltems where each Orderltem is one product. An Order could 
appear as: 

15 

Order 

Orderltem 4x6 print 
Orderltem coffee mug 

20 The above order would have the following bit vector Order . bv [ 1 0 1 ] . Initially, 

the method may save the enumeration of the fulfiller hash table in another vector called 
A11F [Fi F 2 F 3 ]. The sequence of the fulfillers in this vector is subject to change. All 
of the fulfillers may be saved in another vector and ordered by the number of products they 
fulfill; this is called vector AllFByCount [F 3 Fi F 2 ]. F 3 has the most products so it 

25 appears first in the vector. The sequence of this vector is fixed and will not change. As 
described in further detail below, the basic approach adopted includes performing bitwise 
ANDing operations of the bit vectors, to generate an Order bit vector representing the 
optimized fulfillment (per system configuration/constraints) for a particular received order. 
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D. Order Scheduler components 

As shown in Fig. 5 A, a server-based order scheduler system 500 constructed in 
accordance with the present invention includes an order parser 510, an order engine 520, an 
order scheduler 530, an order processing module 540, and a back-end (SQL) database 550. 
5 The order parser 5 10 receives XML requests (e.g., via HTTP, FTP, or the like) that comprise 
order information for orders that are to be fulfilled. The parsed information, in turn, is stored 
in the database 550 as an order (comprising one or more order items) in ORDER„T and 
0RDER_ITEM_T tables. The order engine 520 may now invoke various components for 
handling the database-logged order. In particular, the engine 520 invokes the order scheduler 
10 530, described in further detail below, for optimizing fulfillment of each received order. 
Once the desired optimized fulfillment of a particular order has been determined, the order 
processing module 540 is invoked for actual processing of the order, such as submitting 
online fulfillment requests (i.e., order to particular fulfillers) and/or generating hardcopy 
documents, as desired. 

15 Of particular interest is the order scheduler 530, which is illustrated in greater detail 

in Fig. 5B. As shown, the order scheduler 530 includes a scheduler core or engine 531, a 
database interface 533, and a configuration/constraints module 535. These modules are 
implemented as server-side Java components (servlets). The scheduler core 531 implements 
the core logic for optimizing fulfillment of orders; its detailed operation is discussed below. 

20 The database interface 533 provides databases connectivity (including SQL query ability) to 
the back-end database. The configuration/constraints module 535 allows specification of 
various policies, including configuration settings and fulfillment constraints. For example, 
the module 535 may be employed to specify a fulfillment constraint that a particular 
fulfiller/supplier is most favored. Additionally, the module 535 allows specification that 

25 orders are to be fulfilled by proximity (of fulfiller to customer), by count (of order items per 
fulfiller), or the like. 

Fig. 5C illustrates construction of the database 550 in further detail. The database 
itself may be implemented as an SQL-based relational database, such as an Oracle database 
(e.g., in Oracle 8i> available from Oracle Corporation of Redwood Shores, CA). In 
30 particular, the figure demonstrates a database schema employed for the database 550 in the 
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currently-preferred embodiment. The following database tables are of particular interest in 
the database schema: 

ORDER__T -- describes an order, has a set of order items; 

0RDER_ITEM_T — describes what the product and order item specialty is that a user 
5 ordered; 

FULFiLLER__ORDER_jr - allows splitting an order into multiple fulfiller orders 
(sub-orders); 

FULFILLER_ORDER_ITEM_T similar to ORDER_ITEM_T but represents the 
order items in a sub-order; 
10 PRODUCT_T - describes a product, e.g., a 4x6 photo print, or the like; and 

PRODUC T_JFULF I LLER__T -- associates which products are available for which 
fulfillers. 

E. Detailed Operations 

15 1. High-level method of operation 

Fig. 6 is a flowchart summarizing overall operation of the system. As shown at step 
600, the bit vectors mapping product availability for each fulfiller are routinely updated from 
the database. This updating includes adding/deleting fulfillers to a vector of fulfillers. The 
updating may include refreshing each bit according to periodic updates in inventory tables, in 

20 cases of extended implementations of the preferred embodiment that incorporate inventory 
data. During the update, each fulfiller is allotted a bit vector with a matching number of 
elements as the product hash table has cells corresponding to all the products (Pi, P 2 , ... Pn) 
provided by the middleman. A new vector is built for each fulfiller, wherein each element, 
or bit, in the vector (which corresponds to each product type of the middleman, in the product 

25 hash table) is set to 1, for true, if the fulfiller provides that product. Otherwise, that bit is set 
to 0, for false if the fulfiller does not provide this type of product. Therefore, if the 
middleman offers three types of products, and a particular fulfiller does provides the second 
and third products (as represented by the product hash table) the fulfiller's bit vector would 
be set to "011". 
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At step 610, the middleman sets the scheduling policy for determining the selection 
criteria for the fulfiller precedence, or sort-ordering in a vector of all the fullfillers' bit 
vectors. In the most general case, the selection criteria, or constraint, is to minimize the 
number of fulfillers splitting the fulfillment of each individual middleman order. The sort- 
5 ordering of a vector of all fulfillers reflects the selection criteria by advancing the fulfiller 
whose most satisfies that criteria to the front of a runtime vector of fulfillers' bit vectors, 
AllF [ ] . bv. When a fulfillment order is scheduled, the fulfiller vector is processed 
sequentially from element 0 to element N-l. Fulfillers at the front of the fulfiller vector have 
an earlier opportunity to fulfill each order item in a fulfillment order. 

10 At step 620, the order scheduler engine (described above) fetches a fulfillment order 

request. The order parser had already populated the database with the order data when the 
XML-encoded order request was received by either an HTTP or an FTP communication with 
the order-generating client (e.g., order entry at a PC). At step 630, the order items requested 
in the fulfillment order are mapped to the product items in the middleman's product line, the 

15 product hash table. Using the same bit vector mapping for the order's bit vector as was used 
at step 610 (in creating each fulfiller's bit vector: order items whose product type matched 
one of the middleman's product types), at step 630, an order bit vector is populated for the 
current order. Using the same logic as was used at step 610, at step 630, a new order vector 
is built for the current order, wherein each element, or bit, in the vector (which corresponds 

20 to each product type of the middleman, in the product hash table) is set to 1, for true, if the 
order requests that product. Otherwise, that bit is set to 0, for false if the order does not 
request this type of product. Therefore, if the middleman offers three types of products, and 
a particular order requests the first and second products (as sequenced in the product hash 
table) the fulfiller's bit vector would be set to "110". 

25 At step 640, the order scheduler 430 walks through the fulfiller vector, executing a 

bitwise & ("AND") operation on the current fulfiller bit vector and the order bit vector. If the 
bitwise & operation on these two bit vectors results in a bit vector with the same bit sequence 
as the order bit vector, then step 640 successfully fulfills the entire order with a single 
fulfiller (the most optimal condition), exits, and jumps ahead to step 670. If a single fuller 

30 cannot fulfill an entire order, then the order fulfillment must be split across multiple 

fulfillers; the method proceeds to the next step. At step 650, the order scheduler 430 walks 
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through the sort-ordered fulfiller vector, traverses each fulfiller's product vector, and executes 
a bitwise & ("AND") operation on the current fulfiller bit vector and an order item bit vector 
for each order item in the order bit vector. While the order bit vector is a "bitwise OR" of all 
the order items, the order item bit vector has only 1 bit set. For example, if the order bit 
5 vector is represented by "101", the order item bit vector for the third product would be "001". 
The order item bit vector is a temporary structure used to determine where the order items 
should be placed in the three-dimensional data structure shown in Fig. 4A. In this step the 
order scheduler 430 places order items with multiple fulfillers, rather than placing the whole 
order with a single fulfiller. The following Java snippet tests an order item with the types of 

10 products offered by the earliest selected fulfiller: 

(AllFSortedForAscendingProver [0] .bv & Orderltem.bv) == Orderltem.bv 

If the Orderltem cannot be placed in Al lFSor t edForAscendingProver [ 0 ] then the 
order scheduler 430 tries the next index, AllFSortedForAscendingProver [ 1 ] and 

15 so on until this order item is placed with a fulfiller. This iteration is run against every order 
item sequentially in a single pass through a sort-ordered list of fulfiller. 

The preferred embodiment depends upon a statistically likely optimization of a 
minimum set of fulfillers for an order; therefore, computation time is minimal. The base 
program module is implemented for the present invention, thereby freeing programmatic 

20 resources for the middleman, and it need not be modified. However, it does serve as an 

implementation design that application developers can use to further refine their scheduling 
algorithms. At step 650, ancillary constraints may be accounted for by re-sort-ordering the 
fulfillers' vector (i.e., a fulfiller preference vector). For example, to implement another 
selection criteria, such as "favored fulfiller", the index position(s) for the favored fulfiller(s) 

25 can be re-indexed to the beginning of the fulfillers' vector. 

At step 660, as the order items among the split order are being placed with providing 
fulfillers, the order scheduler 430 populates a subsequent dimension (VPi, described above) 
for the two-dimensional matrix mapping fulfiller products with the middleman's product line. 
This third, or higher, dimension represents collections (vectors) of order requests for the 

30 same type of product offering, but with subtler typing information in the description of an 
order item. For example, using an e-commercial photographic printing service as a fictitious 
fulfiller or middleman, three types of products are offered: 4x6 prints, 8x10 prints, and 11x14 



Page 21 of 40 



prints. The product type, 4x6 prints, is represented by a cell in the 2-dimensional hash tables 
matrix (as previously described). However, an order may list a 4x6 print as two separate 
order items: one 4x6 print might be of the owner's dog, whereas the subsequent 4x6 print 
might be of the owner's cat. In this example scenario, both 4x6 order items would be placed 
5 with the same fulfiller, who provides 4x6 prints, and each placement would be recorded in a 
separate element along the VP* vector indexed at the 4x6 product type for the current 
fulfiller. 

When scheduling a split order, the creation of a new set of fulfillment orders (to be 
placed with multiple fulfillers) that contains only a subset of the order items in the original 

10 customer order, is termed a sub-order. At step 660 the fulfillers vector is walked, nesting 
another walk along the fulfiller's product bit vector, and at each index in the 2-dimensional 
matrix traverse along the corresponding VPi vector, gathering order items placed along the 
VPi vector to be placed in each provider's sub-order. 

Step 660 is the final step necessary to schedule an order fulfillment. However, before 

15 re-cycling through the sequence envisioned in Fig. 6 for fulfilling another order, the 

middleman may desire to re-order the sort-ordered fulfiller vector. At step 670, ancillary 
constraints may be accounted for by modifying the sort-ordered fulfiller vector, or fulfiller 
preference vector, outside of the execution loop that processes the scheduling of the 
fulfillment of each order. For example, if "fulfiller placement fairness" were an additional 

20 selection criteria (including the minimum number of fulfillers criteria), then subsequent to 
fulfilling an order, the elements in the sort-ordered fulfiller vector move one index closer to 
the front of the vector (e.g., AllF [ 0 ] ) to enable round-robin fulfiller preference. 

2, Probable Fulfillers 

Fig. 7 is a flowchart illustrating a coarse-grained optimization method for fulfilling an 
25 order with a relatively low number of fulfillers. The underlying model for this single-pass 
method is that sort-ordering ranking fulfillers according to the number of order items in the 
current order each fulfiller can place or "fulfill," results in a statistically improved likelihood 
of scheduling this order with a lower-than-average number of fulfillers. At step 700, each 
fulfiller from a fulfiller vector gets the number of order items it can place, with a method, 
30 AllF [ ] . count ( ) . At step 720, the vector of fulfillers, AllF [ ] , is sorted, in descending 
order, according to the number of order items that fulfiller can place. At steps 640 and 650, 
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these steps proceed as previously described for steps 640 and 650 in Fig. 6. The method, 
described in Fig. 7, minimizes shipping costs by minimizing the number of disparate 
fulfillers, or sub-orders, each of which would likely attach a levy for basic services rendered. 

3. Minimal shipping distance 

5 Figs. 8 is a flowchart illustrating the methodology of the preferred embodiment 

processing arbitrary logic to arrive at an optimized fulfillment schedule for an order. Fig. 8 
describes the middleman method for minimizing shipping costs by placing order items with 
fulfillers geographically nearest to the delivery address. Minimizing shipping distance 
lowers shipping costs. At step 800, the geographical proximity of each fulfiller to the 

10 delivery address is calculated. This method utilizes the zip code prefixes and corresponding 
postal zones as devised by the United States Postal Service. These prefixes typically 
comprise the three most significant digits of a zip code and define rather distinct 
geographical locations. Since localities in the United States are parceled into postal zones 
designated by zip codes, utilization of zip code prefixes readily provides a means for 

15 identifying any geographical location in the country. 

At step 820, a method ranks fulfillers according to their proximity to the delivery 
address of a sub-order shipment. The fulfiller vector, AllFByProximity [ ] , is sort- 
ordered from the least distant shipping route (to the delivery address) to the most distant. 
The proximity values are calculated as follows. First (for the continental United States), the 

20 numeric shipping zone (i.e., the above-mentioned United States Postal Service-designated 
shipping zones) of the delivery address is calculated using that address's zip code. The 
numeric shipping zone of the each fulfiller was already fetched from the database. Now the 
two endpoints of a shipping route, both the fulfiller and the delivery address, are represented 
by an integer in the set of shipping zones, 0-9. Adjacent zones have successive zone values. 

25 Second, the numeric difference between the value of the delivery address shipping zone and 
the value of a fulfiller's shipping zone is the fulfiller's proximity value. The lower that 
numeric difference, the greater the fulfiller's proximity. For example, addresses in zone 2 
have the highest proximity to fulfillers also in zone 2. Their proximity values would be 0. 
The next highest proximity for addresses in zone 2 would be both zone 1 and zone 3. Third, 

30 in determining the proximity value for a fulfiller in another zone, the value of the shipping 
zone of the delivery address is both incremented/decremented to test for "next best 
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10 



proximity." In this example, the fulfilled shipping zone value (2) would be compared with 
zone 1 and then with zone 3. Fourth would be an iteration of the previous step, but the 
already incremented/decremented delivery address zones are yet again 
incremented/decremented. In this example, the fulfiller's shipping zone value (2) would be 
compared with zone 0 and then with zone 4. 

At step 640, the sort-ordered vector of fulfillers, AllFByProximity [ ] , is tested to 
determine if the order can be fulfilled by a single fulfiller: Each fulfiller bit vector is 
processed with the order bit vector with a "bitwise &" operation to place order items with 
fulfillers preferred by their proximity. At step 650, the sort-ordered vector of fulfillers' bit 
vectors, AllFByProximity [ ] . bv, is processed as previously described at step 650 in 
Fig. 6. The fulfillers' vector is created by a byProximi ty ( ) method. 

The byProximi ty ( ) method itself may be implemented as follows (shown in Java 

code). 



15 



20 



40 



45 



1: // Return a list of fulfillers ordered by those closest to this 
zipCode 



public Vector byProximi ty (String zipCode) { 
in t z oneO f Z ipC ode ; 

Vector vectorOf Fulfillers = new Vector {); 
Vector fulf illersTmp; 
int step - 1; 
boolean keepGoing; 
int i ; 



25 


10: 


II 


The 


first digit 




country. 








11 


II 


The 


areas are : 




12 


II 


0 


Northeast 




13 


II 


1 


NewYork 


30 


14 


II 


2 


MidAtlantic 




15 


II 


3 


Southeast 




16 


II 


4 


GreatLakes 




17 


II 


5 


Midwest 




18 


: // 


6 


Plains 


35 


19 


: // 


7 


Southwest 




20 


: // 


8 


Western 




21 


: // 


9 


Pacific 




22 


: // 


This informatio] 



post office 

23: // maps. So the names may not be correct but it is close enough 

for postal work. 
24: 

try { 

zoneOf ZipCode = Integer .parselnt (zipCode . substring (0 , 1) ) ; 
} catch (Exception e) { 

return vectorOf Fulf illers ; // passed in a malformed zip code 



25 
26 
27 
28 
29 
30 
31 



fulf illersTmp = Fulf iller . getByZone ( zoneOf ZipCode) ; 
for (i = 0; i < fulf illersTmp . size () ; i++) 
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32: vectorOfFulfillers.addElement ( fulfil lersTmp . element At (i) ) ; 

33! 

34: while (true) { 
35: keepGoing = false; 

5 36: , , . 

37 . //we may get a zone in the middle of the country so we need to 

step 

38: // away 1 zone at a time to make sure that we get the fulfillers 

closest 

10 39: // to this zone 

40: 

41: if (zoneOfZipCode + step <= Fulf iller .LAST_ZIP_ZONE) { 

42: fulf illersTmp = Fulf iller .getByZone (zoneOf ZipCode + step); 

43: for (i = 0; i < fulf illersTmp . size () ; i++) 

15 44 : vectorOfFulfillers.addElement (fulf illersTmp. elementAt (1) ) ; 

45: keepGoing = true; 

46: } 
47 : 

48: if (zoneOf ZipCode - step >= Fulf iller . FIRST_ZIP_ZONE) { 

20 49: fulf illersTmp = Fulf iller . getByZone ( zoneOf ZipCode - step); 

50* for (i = 0; i < fulf illersTmp . size () ; i++) 

51; vectorOfFulfillers.addElement (fulf illersTmp. elementAt (i) ) ; 

52: keepGoing = true; 

53: } 
25 54: 

55: if (keepGoing == true) 

56: step++; 
57: else 
58: break; 
30 59: 

60: } // end while true 

61: 

62: return vectorOf Fulf illers ; 



63: } 
35 64: 

As shown by lines 41 and 48, the method builds a list of who are the fulfiller(s) in the 
immediate and then neighboring ZIP code regions. The method proceeds to add fulfillers 
from other ZIP code regions, proceeding from nearest to farthest (from the customer), until 

40 all fulfillers have been ranked by proximity. 

Appended herewith as Appendix A are source code listings in the Java programming 
language, providing further description of the present invention. A suitable development 
environment for compiling Java code is available from a variety of vendors, including 
Borland Software Corporation (formerly, Inprise Corporation) of Scotts Valley, CA and Sun 

45 Microsystems of Mountain View, CA. Appendix A is hereby incorporated by reference. 

While the invention is described in some detail with specific reference to a single- 
preferred embodiment and certain alternatives, there is no intent to limit the invention to that 
particular embodiment or those specific alternatives. For instance, those skilled in the art 
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will appreciate that modifications may be made to the preferred embodiment without 
departing from the teachings of the present invention. 
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APPENDIX A: SOURCE CODE LISTINGS 



/* ProjectName : ePhoto.com 
*/ 

5 /* ModuleName : ec . fulfillment */ 

/* File : DistributeOrders . java */ 

/* */ 

/* Copyright 1998-2000 by LightSurf Technologies., */ 

/* 110, Cooper Street, Santa Cruz, CA-95060, U.S.A. */ 

10 /* All rights reserved. */ 

/* */ 

/* This software is the confidential and proprietary information */ 

/* of LightSurf Technologies. ("Confidential Information"). */ 

/* You shall not disclose such Confidential Information and shall use */ 

15 /* it only in accordance with the terms of the license agreement */ 

/* you entered into with LightSurf Technologies. */ 



package com. lightsurf . ec . fulfillment ; 

20 import java.util.*; 

import j ava . sql . * ; 

//import com. lightsurf .API , * ; 

import com. lightsurf .util . Conf ig; 

import com . lightsurf . ec .API . Table ; 
25 import com. lightsurf . ec .API . DBContext; 

import com. lightsurf . ec . API . Persistance; 

import com. lightsurf . services . ecomm. Order; 

import com. lightsurf . services . ecomm. Order I tern; 

//import com. lightsurf . ec . API . OrderTable; 
30 import com. lightsurf. services. ecomm. Address; 

import com. lightsurf . services . ecomm. Product; 

import com. lightsurf . services . ecomm. EcommService ; 

import com. lightsurf . ec . fulf ailment .Fulf illerOrder; 

import j avax . servlet . ServletContext ,- 
35 import com. lightsurf . services . ecomm. EcommService ; 

/ * * 

* This class looks through the order table for new orders and rewrites 
them as 

40 * Fulf illerOrders . The Fulf illerOrder maintains similar links to Order 
but is 

* much smaller. An Order can have several different shipping addresses. 
The 

* Fulf illerOrder only has 1 shipping address. This class splits 1 order 
45 into 

* 1 or more Fulf illerOrder objects by unique address. 
* 

* ^author John Rodriguez 

* Aversion 0.1 
50 */ 

public class DistributeOrders extends Persistance 
{ 

static final boolean debug = false; 

55 

// Currently the bit vector size is 64 (long) . This limits the scheduler 
to 64 products 

// and 64 fulfillers. This assumption has sped up both the 
implementation of the 
60 // scheduler as well as it's performance. Actually, the bit vector could 

be any 
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// arbitrary length. If 64 is too restrictive, I will write a general 
bit vector 

// package that handles arbitrary number of products or fulfillers. 

5 // There could be more scheduling modes than the following 2 modes. For 

now, these 

// 2 should show what needs to be done for 2 different scheduling modes, 
final static public int SCHEDULE_BY_COUNT = 0; 
final static public int SCHEDULE_BY_PROXIMITY = 1; 
10 final static public int SCHEDULE_MODES_MAX = SC HEDUL E_BY_PR0X I M I T Y ; 

// This object is only used for the monitor of the wait/notify 
Integer syncObj = new Integer (1); 

15 // If we were started by a servlet, remember the context for logging. 

ServletContext context = null; 

// Save all the fulfillers. 

private Vector fulfillers = null; // for HF 
20 // Save all the products 

private Product [] products = null; // for HP 

// The schedulerTable is a data structure whose rows are represented by 

a 

25 // HashTable of fulfillers (HF) , where each column is a hashtable of 

products (HP) 

// and where each indice of HP is itself a vector (VPi) . For more detail 

on 

// how these data structures are used, see the document "Order 
30 Scheduler" by 

// John Rodriguez 
Hashtable HF; 
Hashtable HP; 
Vector VPi; 

35 

// This vector of all the fulfillers changes as we distribute orders 
Vector AllF = new Vector (); 
Vector AllFByCount = new Vector () ; 
Vector AllFBy Proximity = new Vector (); 

40 

EcommService service = EcommService. SYSTEM_ECOMM_SERVICE; 

public DistributeOrders {ServletContext context) { 

int i, j; 
45 Ful filler f, fTmp; 

int productCount; 

Vector productFulf illers; 

ProductFulf iller productFulf iller ; 

Product prod; 
50 int numberOf Products ; 

this. context = context; 

try { 

55 products = service . selectProducts () ; 

numberOf Products = products . length ; 

ProductFulf iller . init { ) ; 

productFulf illers = ProductFulf iller .get All Pro ducts {) ; 
60 Fulf iller. init () ; 

fulfillers = Fulf iller .getAllFulf illers () ; 

HF = new Hashtable ( fulf illers . size ()) ; 
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// Build the main data structure for scheduling 
for (i = 0; i < fulf illers . size { ) ; i++> { 
HP = new Hashtable(numberOf Products) ; 

5 f = (Fulf iller) fulf illers. elementAt(i) ; 

AllF.addElement (f ) ; 

// Build the AllFByCount vector in descending product count order 
if (AllFByCount. si ze ( ) == 0) { 
AllFByCount . addElement ( f ) ; 

10 } 

else { 

AllFByCount . insertElementAt (f , 0) ; 

// Build the AllFByCount in place rather than sorting later 
for (j = 1; j < AllFByCount. si ze ( ) ; j++) { 
15 fTmp = (Fulf iller) fulf illers .elementAt (j ) ; 

if (f .getProductCount () < fTmp. get Product Count () ) { 
// Switch places 

AllFByCount . insertElementAt ( f , j ) ; 
AllFByCount . insertElementAt ( fTmp, j -1 ) ; 

20 } 

else { 

break ; 

} 

} // end for 

25 } 

for (j = 0; j < products. length; j++) { 
prod = products [j ] ; 
if (debug) 

30 System, out. println ( "productFulf iller product__id " + 

prod. get Product ID () ) ; 

if (HP.containsKey (new Long (prod. getProduct ID ()) ) == false) { 
VPi = new Vector (); 

HP.put(new Long (prod. getProduct ID {)) , VPi); 

35 } 

} 

HF. put (new Integer ( f .hashCode () ) , HP); 
} 

40 // Build the bitPattern manipulation data structure. I have chosen 

a long 

// for efficiency. This means that the number of products must be 
less than 64 

// and the number of fulf illers must be less than 64. I could 
45 write a general 

// bit vector package that would allow for any number of products 
or fulfillers 

// but it would be slower. I think in the general case that 64 
should be enough. 

50 //If this proves not to be the case, then I will write the 

general bit vector 

// package later. 

// Notice that the bit vectors are indexed according to the 
ProductFulf iller table 
55 // and not the Product table. 

ProductFulf iller product; 
long bv; 

for (i = 0; i < products . length; i++) { 
prod = products [i]; 
60 bv = 1 « i; 

if (debug) 

System. out .println ( "productFulf illers size " + 
productFulf illers . size ( ) ) ; 

for (j = 0; j < productFulf illers . size () ; j++) { 
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product = (ProductFulf iller)productFulf illers.elementAt (j) ; 
if (debug) 

System. out .println( "product pfulfiller id " + 
prod.getProductID( ) + " " + product . getProduct ID ()) ; 
5 if (prod.getProductID{) == product . getProductID () ) { 

product .orBV(bv) ; 
} 

} 
} 

10 

if (debug) { 

for (j = 0; j < productFulf illers . size ( ) ; j++) { 

product = ( ProductFulf iller) productFulf illers. elementAt ( j ) ; 
System. out .print In ( "pfulfiller " + 
15 product .getFulf iller ID ( ) + " " + product . getBV{ )) ; 
} 
} 

// Copy the bit pattern just set above to the fulf iller fulf iller. 
20 //A fulf iller has a row for each product they carry in the 

ProductFulf iller table. 

ford = 0; i<fulf illers . size {) ; i++) 
{ 

Fulfiller fulfiller = (Fulf iller) fulf illers . elementAt ( i) ; 
25 for (j = 0; j < productFulf illers . size () ; j++ ) { 

product = 

(ProductFulf iller ) productFulf illers .elementAt ( j ) ; 
if (debug) 

Sys tem. ou t. print In ( "product fulfiller id " + 
30 product. getFulf iller ID () + " " + fulf iller. getFulf iller ID() ) ; 

if (product. getFulf illerlDO == 
fulf iller. getFulf illerlDO ) { 

fulfiller. orBV (product. getBVO ) ; // this represents the 

list of products 
35 } 

} // end for j 

} 

if (debug) { 

40 for (j = 0; j < fulf illers. size () ; j++) { 

Fulfiller fulfiller = {Fulf iller) fulf illers . elementAt (j ) ; 

System. out .printing "fulfiller bv " + fulf iller. getBVO ) ; 

} 
} 

45 } catch (Exception e) { 

if ( (Conf ig.ERROR_LEVEL Sc Conf ig . DEBUG_FULFILLMENT) > 0 ) 
System. err .println ( " [error_fulf illment ] DistributeOrders : 
exception during initialization"); 
e .print StackTrace O ; 

50 } 

} 



// Find all new orders and add rewrite the Order as a Fulf illerOrder 
public void distributeNewOrders (Vector fulf illerOrders , int 
55 schedulingMode) { 



if (debug) 

System. out .println ( "Start distributeNewOrders") ; 

60 if {schedulingMode < DistributeOrders . SCHEDULE_BY_COUNT || 

schedulingMode > DistributeOrders . SCHEDULE_MODES_MAX) { 
System. err .println ( "distributeOrders : bad scheduling mode " + 
schedulingMode) ; 

return; 
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} 

Vector fulf illerOrderl terns ; 

Order order; 
5 Orderltem orderltem; 

Orderltem orderlteml = null; 

Fulf illerOrder f Order = null; 

Fulf illerOrderltem f Orderltem = null; 

int i, j, k; 
10 Address shippingAddress ; 

Long longVal, bitVal; 

Fulfiller fulfiller; 

ProductFulf iller productFulf iller ; 

boolean orderDone = true; 
15 Vector saveNewOrders = new Vector (); 

i f ( debug ) 

System. out .println ( "distributeNewOrders start") ; 

20 if {fulfillerOrders != null) { 

for (i = 0; i < fulfillerOrders - size () ; i++) { 

fOrder = (Fulf illerOrder) fulf illerOrders . elementAt (i) ; 

fulf illerOrder It ems = f Order . getl terns {) ; 

// This initializes the Order and Orderltem for later 
comparisons . 

30 for (j = 0; j < fulf illerOrderltems . size () ; j ++) { 

// Need to compare against product id 
f Orderltem = 

(Fulf illerOrderltem) fulf illerOrderltems . elementAt (j ) ; 
order = f Order .getParentOrder () ; 
35 orderltem = order .getOrderl tem (f Orderltem. getOrderltemID {) ) 

Vector pFs - 

ProductFulf iller . getProduct (f Orderltem. getFulf illerlD ( ) ) ; 
for (k = 0; k < pFs.sizeO ;k++) { 

ProductFulf iller = ( ProductFulf iller) pFs . elementAt (k) ; 
40 if (orderltem. get ProductID() == 

productFulf iller , getProduct ID ( ) ) { 

//An Order will have all the products or'ed in. 
f Order .orBV (productFulf iller. getBVO ) ; 
//An Orderltem will have just the bit for this 



25 



45 product or'ed in, 

} 



50 



fOrderltem.orBV (productFulf iller. getBVO ) ; 

} 



} 



// Get the first fulfiller 

fulfiller = (Fulfiller) AllF. elementAt (0) ; 



orderDone = false; 

55 if (schedulingMode == DistributeOrders . SCHEDULE_BY_COUNT && 

(fulf iller. getBVO & f Order. getBV () ) == f Order . getBVO ) { 
long fid = fulf iller . getFulf illerlD () ; 
fOrder.setFulfillerlD(fid) ; 

for (j = 0; j < fulf illerOrderltems . size () ; j ++) { 
60 fOrderltem = 

(Fulf illerOrderltem) fulf illerOrderltems . elementAt ( j ) ; 

fOrderltem. setFulf illerlD ( fid) ; 

} 

//we are done with this order 
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f Order. setStatus (Fulf illerOrder . STATUS_PENDING) ; 
orderDone = true; 

} 

if (orderDone == false) { 

Vector newFulf illerOrders; 

// This will return a Vector of 2 or more Fulf illerOrders . 
// split from the original Fulf illerOrder . 

newFulf illerOrders = ScheduleOrders ( f Order , schedulingMode) ; 



if (newFulf illerOrders != null) { 
15 for (k =0; k < newFulf illerOrders . size () ; k++) 

saveNewOrders . addElement (newFulf illerOrders . elementAt (k) ) ; 

newFulf illerOrders . remove All Elements { ) ; 
// Get rid of this order because it has been split 
20 fulf illerOrders . removeElementAt (i) ; i — ; 

} 

} 

25 if (schedulingMode == DistributeOrders . SCHEDULE_BY_COUNT) { 

// change the sequence of fulfillers in AllF 
Object obj = AllF. elementAt (0) ; 
AllF . removeElementAt ( 0 ) ; 
AllF. addElement (obj ) ; 

30 } 

} // end for i 
if (debug) { 

35 for (i =0; i < saveNewOrders . size {) ; i++) 

System, out .print In (i + " fid=" +■ 
( (Fulf illerOrder) saveNewOrders .elementAt (i) ) . getFulf illerlD ( ) ) ; 
} 

40 for (i =0; i < saveNewOrders . size () ; i++) 

fulf illerOrders . addElement ( saveNewOrders . elementAt ( i) ) ; 

if (debug) { 

for (i =0; i < fulf illerOrders . size () ; i++) 
45 System, out .print In (i + ,l fid=" + 

( (Fulf illerOrder) fulf illerOrders. elementAt (i) ) .getFulf illerlD ( ) ) ; 
} 



saveNewOrders . remove All Elements ( ) ; 

} // end fulf illerOrders 1= null 
} // end processNewOrders 



// Split is given a Fulf illerOrder that could not be scheduled with the 
55 first 

// fulfiller on the list. It will have to be broken up across multiple 
fulfillers . 

// Pass back a vector of newly split Fulf illerOrders . We use the HF, HP 
and VPi 

60 //to see if we can place the Fulf ill erOrder I terns in a slot. 

//If the f Order was not able to be split, this is an error. Log it and 
pass back null. 

//We could be passing in several different vectors for AllFVector 
(AllF, AllFBy Count, 
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// AllFByProximity, etc) 

private Vector ScheduleOrders (Fulf illerOrder fOrder, int schedulingMode) 

{ 

5 Vector newFulf illerOrders = new Vector (); 

Vector f Orderltems = f Order . get I terns ( ) ; 

Fulf illerOrder I tern fOrderltem; 

Fulfiller fulfiller; 

ProductFulf iller productFulf iller ; 
10 Fulf illerOrder newFulf illerOrder; 

Product product; 

Vector AllFVector; 

Order order; 

Orderltem orderltem; 
15 int numberScheduled = 0; 

int i, j, k; 

for (i = 0; i < f Orderltems . size () ; i++) { 
20 fOrderltem = (Fulf illerOrder Item) f Order It ems . element At (i) ; 



order = f Order . get Parent Order { ) ; 

orderltem = order . getOrderl tern { fOrderltem. getOrderltemID ()) ; 
//we should use an orderltem but it is not set yet, use Order for 

25 now 

// Address address = 
Address . getAddressBylD (orderltem. getShippingAddress ID ( ) ) ; 

//Address address = 
Address . getAddressByTypeAndID (Address .TYPE_SHIP PING, 
30 order . getShippingAddressID ( ) ) ; 

Address address = null; 
try { 

address = 

service . selectMostRecentAddress (order . getShippingAddressID ( ) , 
35 Address . TYPE_SHIPPING) ; 

} catch (Exception e) { 

System. err .print In (" ScheduleOrders : could not get 
selectMostRecntAddress" ) ; 

e .printStackTrace ( ) ; 
40 return new Vector () ; 

} 



if (debug) 

System. out. println("zip is " + address .getPostalCode( )) ; 
45 if (schedulingMode == DistributeOrders . SCHEDULE_BY_PROXIMITY) 

AllFVector = byProximity (address . get PostalCode {)) ; 
else 

AllFVector = AllFByCount; 
50 for (j = 0; j < AllFVector. size () ; j++) { 



// See if we can place the Fulf illerOrderltem at this fulfiller 
fulfiller = (Fulfiller) AllFVector. elementAt(j) ; 

55 if (debug) 

System. out .println { fulf iller. getClass () + " fBV foiBV " + 
fulfiller. getBVO + " " + fOrderltem. getBV( )) ; 

if ( (fulfiller. getBVO & fOrderltem. get BV( ) ) == 
60 fOrderltem . ge tBV ( ) ) { 

// place in HF, HP, VPi 

HP = (Hashtable) HF.get(new Integer (fulf iller .hashCode ())) ; 
//order = f Order .get ParentOrder () ; 



Page 33 of 40 



f 



10 



30 



35 



/ /orderitem = 

order . get0rderltem(f Orderltem. getFulf illerOrderltemID ( ) ) ; 

VPi = (Vector) HP . get (new Long (orderltem. get ProductID ())) ; 
VPi . addElement ( f Orderltem) ; 

f Orderltem. setFulf illerlD ( f ulf iller . getFulf illerlD ( ) ) ; 
fOrder.setFulfillerID(fulfiller.getFulfillerID() ) ; 
numberScheduled++ ; 
break; 

} 

} // end for j 
} // end for i 



if ( f Order I terns . size ( ) == numberScheduled) { 
15 // This should always be the case, anything else is an error 

// Walk through HF, HP and VPi making a new Fulf illerOrder for 
each row of HF 

// that has any Fulf illerOrderl terns 
for (i = 0; i < fulf illers . size () ; i++) { 
20 newFulf illerOrder = null; 

fulf iller = (Fulf iller) fulf illers. elementAt (i) ; 
HP = (Hashtable)HF.get (new Integer (fulf iller .hashCode ())) ; 
for (j = 0; j < products . length; j++) { 
product = products [j ] ; 
25 VPi = (Vector) HP. get (new Long (product. getProductlDO )) ; 

if (VPi. size () > 0) { 

for (k = 0; k < VPi.sizeO; k++) { 
if (newFulf illerOrder == null) { 

newFulf illerOrder = new Fulf illerOrder () ; 



newFulf illerOrder. setFulf illerlD ( f Order. getFulf illerlD () ) ; 

newFulf illerOrder . setOrderlD (f Order .getOrderlD ( ) 

newFulf illerOrder . setParentOrder ( f Order . getParentOrder ( ) ) ; 



newFulf illerOrder. setStatus (Fulf illerOrder . STATUS_JP ENDING) ; 

} 

newFulf illerOrder . addFulf illerOrderltem 
( (Fulf illerOrderltem) VPi. elementAt (k) ) ; 

40 } 

} 

} // end for j, walk through the products 

if (newFulf illerOrder 1= null) 
45 newFulf illerOrders .addElement (newFulf illerOrder) ; 

} // end for i, walk through ful fillers 
} else { 

// This should be logged to a file ! ! ! TBD 
try { 

50 if ( (Config.ERROR_LEVEL & C on f ig.DEBUG_FULF I LLMENT) > 0 ) 

System. err .println ( "Error : fOrderltems 1 = numScheduled for 

f Order= n + 

f Order .getFulf illerOrderlD ( ) ) ; 
} catch (Exception e) {} 
55 System. out .println ( "Error ! 3 i Orders scheduled different than number 

of orderltems" ) ; 

return null; 

} 

60 // Clean up the scheduling data structure 

for (i = 0; i < fulf illers . size () ; i++) { 

fulfiller = (Fulf iller) fulf illers . elementAt (i) ; 

HP = (Hashtable)HF.get (new Integer (fulf iller. hashCode () )> ; 

for (j = 0; j < products . length; j++) { 
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product = products [j ] ; 

VPi = (Vector) HP . get (new Long (product . getProductID ())) ; 
if (VPi. size () > 0) { 

VPi.removeAllElementsO ; // thats it 

5 } 

} // end for j, walk through the products 
} // end for i, walk through fulfillers 

if (newFulf illerOrders . size ( ) > 0) 
10 return newFulf illerOrders ; 

else 

return null; 



15 



60 



} // end ScheduleOrders 



// Just updates the Order status field 

private void updateOrders (Vector newOrders, int status) { 
int i; 

Order order; 
20 if (newOrders != null) { 

for (i = 0; i < newOrders . size () ; i++) { 
try { 

order = (Order) newOrders . element At (i) ; 

25 order . setStatus ( status ) ; 

//order . update (dbc) ; 
service . updateOrder ( order ) ; 
} catch (Exception e) { 
30 e .printStackTrace () ; 

} 

} // end for 
} // end for 
} // end updateOrders 

35 

// Just updates the Fulf illerOrder status field 

private void updateFulf illerOrders (Vector fulf illerOrders , int status) { 
int i; 

Fulf illerOrder fOrder; 
40 if (fulf illerOrders != null) { 

DBContext dbc = new DBContextO; 
try { 

dbc . connect ( ) ; 

for (i = 0; i < fulf illerOrders . size () ; i++) { 
45 fOrder = (Fulf illerOrder) fulf illerOrders . elementAt ( i) ; 

f Order. setStatus ( status) ; 
fOrder . update ( dbc ) ; 

} 

} 

50 catch (SQLExcept ion sqle) {} 

catch (Exception e) { e .printStackTrace () ; } 
finally { 
try { 

dbc . disconnect ( ) ; 

55 } 

catch (SQLException sqle) {} 

} 

} // end for 
} // end updateFulf illerOrders 



// Return a list of fulfillers ordered by those closest to this zipCode 
public Vector byProximity (String zipCode) { 
int zoneOf ZipCode; 

Vector vectorOfFulf illers = new Vector (); 
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Vector fulfil lersTmp; 
int step = 1; 
boolean keepGoing; 
int i ; 
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// maps. So the names may not be correct but it is close enough for 
postal work. 



try { 

25 zoneOf ZipCode = Integer .parselnt (zipCode . substring (0 , 1)); 

} catch (Exception e) { 

return vectorOf Fulf illers ; // passed in a malformed zip code 

} 

f ul fillers Tmp = Fulf iller . getByZone (zoneOf ZipCode) ; 
30 for (i = 0; i < f ulf illersTmp . size ( ) ; i++) 

vectorOf Fulf illers . addElement { fulf illersTmp. elementAt (i) ) ; 



while (true) { 

keepGoing = false; 

//we may get a zone in the middle of the country so we need to step 
// away 1 zone at a time to make sure that we get the fulf illers 
closest 

// to this zone 



if (zoneOf ZipCode + step <= Fulf iller .LAST_ZlP_ZONE) { 

fulf illersTmp = Fulf iller . getByZone { zoneOf ZipCode + step); 
for (i = 0; i < fulf illersTmp . size () ; i++) 

vectorOf Fulf illers. addElement (fulf illersTmp. elementAt (i) ) ; 
45 keepGoing = true; 

} 

if (zoneOf ZipCode - step >= Fulf iller . FIRST_ZIP_ZONE) { 

fulf illersTmp = Fulf iller .getByZone (zoneOf ZipCode - step); 
50 for (i = 0; i < fulf illersTmp . size () ; i++) 

vectorOf Fulf illers . addElement ( fulf illersTmp . elementAt ( i) ) ; 
keepGoing = true; 

} 

55 if (keepGoing == true) 

step++; 
else 
break; 

60 } // end while true 

return vectorOf Fulf illers; 

} 
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